查看原文
其他

软件测试周刊(第44期):"去那么远没问题么?" “没问题。道路笔直畅通无阻,太阳又没下山,油箱满满的。”

毕小烦 毕小烦 2021-11-05

| 编辑:国薇、一口锅、菜菜、静怡、小淑子、夏至


欢迎来到第 44 期!这里记录过去一周我们看到的软件测试及周边的行业动态,周五发布。


本期看点:盒马是如何进行场景模型驱动自动化测试的?测试多少才算够?怎样通过敏捷测试优化业务价值?如何做到高效的 Code Review?字节跳动自研的移动研发工具链 MBox 怎么样?如何转型做产品经理?产品经理必须要掌握的12种思维模型是什么?人既然知道努力就可以进步,为什么还是会不努力?

·

阅读愉快!

软件测试

1. 盒马是如何进行场景模型驱动自动化测试的?

背景:盒马自动化体系发展新挑战


代码覆盖率在超过 50% 之后很难有比较大的提升,需要有基于较全场景的自动化测试体系。


传统自动化的问题


解决思路:模型驱动自动化


要点:


策略:

特征提取、场景建模、链路执行、结果验证、覆盖率分析、缺陷定位及报告。

产品解决方案:架构图


基于核心的场景模型驱动自动化执行过程为基准,分为业务场景建模模块、测试数据生产模块、回归策略执行选择模块、链路用例执行、结果校验以及结果推送模块基于运维视角,包含统计大盘、用例管理等。

原文地址:

https://mp.weixin.qq.com/s/EP9NFVRYvNDY_jNrOsVwwg

2. 测试多少才算够?(英文)

| Google Testing Blog  小淑子(译)

关于测试策略有一个经典的问题:“测试多少才算够?”  这是一个值得所有测试人思考的问题。


有几个很有用的小技巧:


  1. 记录你的测试流程或测试策略

在完整地测试完产品后,你可以回顾沉淀记录你的测试流程和测试策略,这对集成测试和以后的测试都有很大的帮助。

  1. 有坚实的单元测试基础

在谷歌,就要求任何代码的改动都需要通过对应的单元测试检验。

  1. 不要忽视/跳过集成测试

集成测试比完整的端到端测试具有更少的依赖性。在集成测试的过程中,可以让测试更快速、更高效、更可靠地进行。

  1. 端到端的测试 --- 执行完整的用户操作过程

在谷歌,关键目标和用户为实现最终目标而进行的任务旅程 -- 被称为关键用户旅程。记录关键用户旅程,并使用端到端的测试,最好是通过自动化的方式去验证它们。

  1. 理解并实施其他专项测试。

单元、集成和端到端测试主要是解决了产品的功能级别。同时也需要了解其他专项测试包括:性能测试,容错测试,安全测试,隐私测试等。

  1. 理解代码和功能的覆盖率

    • 对于代码覆盖率,重点是识别不同类型代码的覆盖率,包括语句、边缘、分支和条件覆盖率。

    • 对于功能覆盖率,重点是识别特定版本中提交的功能并为其实现创建测试。

    • 对于行为覆盖率,重点是识别关键用户旅程并创建适当的测试来跟踪它们。

  1. 利用各方的反馈来改进测试流程。

通过产品发布后现场收到的反馈,去改进跟踪故障、bug 和其他问题的流程是非常关键的。可以用来提高产品质量以及最大限度地减少后续版本中回归的风险。


原文地址:

https://testing.googleblog.com/2021/06/how-much-testing-is-enough.html

3. 怎样通过敏捷测试优化业务价值?

提到敏捷测试就会提到优化业务价值,优化业务价值是敏捷测试的原则之一,敏捷测试的系列活动都要围绕交付价值服务,那么具体的到底要怎么做才能真正优化业务价值呢?


可以从四个不同维度来思考:

具体怎么做呢?


  1. 从终端用户角度进行测试:在思考、设计测试用例并执行测试的时候,需要考虑用户可能的行为习惯、使用场景等。

  2. 以业务为重点的测试:深刻理解业务流程、以业务为重点的测试。发现关键业务流程中遗漏的点或相应的缺陷。

  1. 映射业务影响:了解外围业务对系统业务的影响, 开展测试活动时可通过业务影响范围,做出测试活动的方向决策,调整测试策略。

  2. 关联业务指标:根据关联业务指标,跟踪、量化测试活动。分析生产环境数据,做好缺陷预防。


原文地址:

https://mp.weixin.qq.com/s/qr1cqWZjz-7QPvIbTX1lwQ

质量效能

1. 如何做到高效的 Code Review?

Code Review 是我们在日常工作中一个重要环节,高质量的 Code Review 可以提高开发流程的标准化程度,成为质量保证和知识共享的重要组成,帮助建立健康的反馈文化,让工程团队可快速扩展。


提交者应该怎么做?


提交代码审查时,需要解释修改代码的动机,鼓励在提交注释中对变更做出一定的解释,从而提高代码文档的质量。代码变更注释应包含 TestPlan,用于描述如何验证这次修改的代码。


提交注释格式如下:

审阅者应该怎么做?


  1. 当审阅者看到代码中的好东西时,应该喊出来,并给出积极的反馈

  2. 任何代码审查的评论都应该做到“不言自明”。如有疑问,最好能进行过度解释,而不是提供简短的反馈。当反馈点内容比较生僻,建议附上一个外链接,以指向其内容解释,供被评者参考学习。

  1. 无论提交代码的结果如何,总要赞赏他们的辛苦工作——它能培养出强大而积极进取的团队。

  2. 避免评审注释太多,将重要问题淹没在次要建议中。当提交者不了解团队编写代码要求时,应进行线下面对面的辅导。


原文地址:

https://mp.weixin.qq.com/s/d-V_Jp4iztFeEuraVBZkiw

2. 字节跳动自研的移动研发工具链 MBox 怎么样?

MBox 是一款面向移动端开发者的研发工具链,它最终所呈现的产品形态是一款包含 GUI (Graphical User Interface) 与 CLI (Command-Line Interface) 的 Navtive App。


MBox 解决了日益复杂的研发环境与工程架构的问题。


  • 研发环境:在大前端背景下,移动端研发环境呈现出丰富的技术栈背景,这也导致了研发环境的复杂度提升。随着工程化推进,环境问题会持续困扰着团队所有成员,环境版本不一致、工程环境冲突、频繁更新文档,这些问题会使得研发人员将大量精力浪费在环境上,而不是核心的编码与测试阶段。

  • 工程架构:很多移动端研发人员经常面对着的是超大型工程或者多个工程并行开发的场景,项目的工程架构往往十分复杂,这通常体现在多仓依赖管理困难、发布流程繁琐、多人协作难度变大,极大地影响研发效率。


MBox 的设计理念是什么?有哪些功能?挑战是什么?优势是什么?


原文地址:

https://mp.weixin.qq.com/s/5_IlQPWnCug_f3SDrnImCw

产品思维

1. 如何转型做产品经理?

有人号称人人都是产品经理,那开发如何转型做产品经理?测试如何转型做产品经理? 运营如何转型做产品经理?


作者从游戏运营成功转型产品经理,分享了一些自己的经验。


原文地址:

https://mp.weixin.qq.com/s/aG_cJTZx6VTepCeno1i3uQ

2. 产品经理必须要掌握的12种思维模型是什么?

  1. PEST 分析:通过 P(政治)、E(经济)、S(社会)、T(技术)来分析一个行业/企业/产品所处市场环境。

  2. SWOT 分析:内部优势、内部劣势、外部机会、外部威胁

  1. PMF 模型:Product Market Fit 的简写,指产品和市场达到最佳的契合点,你所提供的产品正好满足市场的需求,令客户满意,这是创业成功的第一步。

  2. MVP 模型:用最小的成本开发出可表达项目创意、可用且能用于表达核心理念的原型产品,功能极简而且能用于快速验证想法的最小化产品。

  1. AARRR 模型

  2. SMART 模型:Specific(明确)、Measurable(可衡量)、Achievable(可达成)、Relevant(相关)和 Time-bound(有时限)。

  1. 5WHY 分析法:针对一个问题点,连续问 5 个为什么,就可以追到其根本原因。

  2. Y 模型分析法:每个用户需求都能分析到对应的马斯洛需求层次里面去。

  1. KANO 模型分析法:把用户需求分为:基本型需求、期望型需求、兴奋型需求、无差异需求和反向型需求。

  2. 四象限法则:按处理顺序划分为:紧急又重要、重要不紧急、紧急不重要、不紧急不重要。

  1. MECE 原则:不重不漏,是把一些事物分成互斥的类别,并且不遗漏其中任何一个的分类方法。

  2. RFM 模型:根据 3 项指标来描述该客户的价值状况:R:最近一次消费时间、F:消费频率、M:消费金额


原文地址:

https://mp.weixin.qq.com/s/sbuxacPXQK05XSntqfhLZA

个人成长

1. 人既然知道努力就可以进步,为什么还是会不努力?

因为努力了不一定就可以进步。


为什么这么说呢?


先看什么叫努力?努力必须要包含「克服痛苦」的元素在内,每天走 1 W步跟跑五公里相比,后者应该算努力。每天做20个俯卧撑,跟每天做100个比,后者也算努力,每天看一本书,跟看完书做读书笔记相比,后者也算努力。


同样的行为,有时叫努力,有时不叫努力,这取决于参照系。努力应该是不断的突破自己。「努力」逼着你把全部的痛苦聚焦在所谓的「正事」上,也就是,你希望取得「进步」的地方。


那到底怎么样才能进步呢?


用两位美国心理学家艾利克森和普尔的话说,如果你真的想在某个领域里取得进步,你需要做到三个 F。


Focus专注、Feedback反馈、以及 Fix it 修正,概括来说,3F 就是一种刻意为之的练习,这样做是取得进步的一种有效手段。


原文地址:

https://www.zhihu.com/question/22866524/answer/24739101

2. 复盘网飞:随着坦诚的反馈越来越多,工作效率也越来越高

网飞(Netflix),是一家市值超过 2000 亿美元,全球付费订阅用户超 1.9 亿,业务版图遍布近 200 个国家和地区的商业巨头。

作为创始人、总裁兼董事会主席,里德·哈斯廷斯引领网飞实现了强势增长,并坦言这得益于一套违反直觉的管理原则


  • 你不需要取悦你的老板,只要给出坦诚的反馈;

  • 你不需要层层审批,就可以决定出差标准;

  • 你不需要用加班证明自己,只要充分展示自己的才能就可以得到丰厚报酬……

此间种种,莫不让人惊奇和赞叹。

网飞是怎么做到的?背后有着怎样的故事?怎么结合实际引入这套管理方法?


原文地址:

https://mp.weixin.qq.com/s/ExWfXkLPErJXH_rbXw5ASw

开源项目

1. 一款开源的迅雷替代品:WebTorrent

WebTorrent 是一款可边下边播磁力链接下载器。

迅雷有的功能他都有,迅雷没有的他也有,自带边下边播功能。同时支持 BitTorrent 和 WebTorrent 两种协议,在下载 BT 文件时能够拥有更高的连接成功率。


使用时只需要拖动种子文件进软件或在软件内直接粘贴磁力链接地址即可下载,软件下载时会显示 peer 连接数,peer 连接数越大下载速度越大,下载同时你也会给其他人上传数据,人人为我我为人人。


开源地址:

https://github.com/webtorrent/webtorrent


2. 开源书籍:《凤凰架构:构建可靠的大型分布式系统》

这是一部以“如何构建一套可靠的分布式大型软件系统”为叙事主线的开源文档,是一幅帮助开发人员整理现代软件架构各条分支中繁多知识点的技能地图。


开源地址:

https://github.com/fenixsoft/awesome-fenix


在线阅读:

http://icyfenix.cn/

言论

1、

“去那么远没问题么?”

“没问题。道路笔直畅通无阻,太阳又没下山,油箱满满的。”


| 村上春树《海边的卡夫卡》


2、

一个人可以变成什么样的人,他就一定会变成什么样的人。这个需要,我们称之为自我实现。


| 亚伯拉罕-马斯洛

图片

1、有故事的人

2、这就尴尬了

(完)

如果文章对你有帮助,记得留言、点赞、加关注哦!




: . Video Mini Program Like ,轻点两下取消赞 Wow ,轻点两下取消在看

您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存